Method for controlling a quality of service in a mobile communications system

ABSTRACT

In a mobile communications system (BSS, SGSN, GGSN) having a packet data transmission capability, a dynamic packet-based quality of service (QoS) mechanism is provided within a “transmission tunnel” defined by a more static packet data protocol context (PDP context). More particularly, each data packet is arranged to carry at least one QoS parameter, and the scheduling and the policing of the transmission of the data packets is made in packet by packet basis according to this QoS information in the packets, while, however, within the limits set by the PDP context. This concept enables to have any number of QoS profiles in use simultaneously, e.g. a dedicated QoS profile for each of several Internet user applications run in the mobile station (MS) for a IP address. Therefore, the present invention provides support for various Internet applications and their QoS requirements. Moreover, the QoS can be changed at any time after activation of the PDP context, since only the QoS information in the relevant data packets has to be changed.

FIELD OF THE INVENTION

The invention relates to controlling the Quality of Service (QoS) inmobile communications systems having a packet data transmissioncapability.

BACKGROUND OF THE INVENTION

Mobile communications system refers generally to any telecommunicationssystem which enable a wireless communication when users are movingwithin the service area of the system. A typical mobile communicationssystem is a Public Land Mobile Network (PLMN).

Often the mobile communications network is an access network providing auser with a wireless access to external networks, hosts, or servicesoffered by specific service providers.

The general packet radio service GPRS is a new service in the GSM system(Global system for mobile communications), and is one of the objects ofthe standardization work of the GSM phase 2+ at the ETSI (EuropeanTelecommunications Standards Institute). The GPRS operationalenvironment comprises one or more subnetwork service areas, which areinterconnected by a GPRS backbone network. A subnetwork comprises anumber of packet data service nodes SN, which in this application willbe referred to as serving GPRS support nodes SGSN, each of which isconnected to the GSM mobile communication network (typically to basestation systems) in such a way that it can provide a packet service formobile data terminals via several base stations, i.e. cells. Theintermediate mobile communication network provides packet-switched datatransmission between a support node and mobile data terminals. Differentsubnetworks are in turn connected to an external data network, e.g. to apublic switched data network PSPDN, via GPRS gateway support nodes GGSN.The GPRS service thus allows to provide packet data transmission betweenmobile data terminals and external data networks when the GSM networkfunctions as an access network.

In order to access the GPRS services, a MS shall first make its presenceknown to the network by performing a GPRS attach. This operationestablishes a logical link between the MS and the SGSN, and makes the MSavailable for SMS over GPRS, paging via SGSN, and notification ofincoming GPRS data. More particularly, when the MS attaches to the GPRSnetwork, i.e. in a GPRS attach procedure, the SGSN creates a mobilitymanagement context (MM context). Also the authentication of the user iscarried out by the SGSN in the GPRS attach procedure. In order to sendand receive GPRS data, the MS shall activate the packet data addressthat it wants to use, by requesting a PDP activation procedure contexts(PDP, Packet Data Protocol). This operation makes the MS known in thecorresponding GGSN, and interworking with external data networks cancommence. More, particularly a PDP context is created in the MS and theGGSN and the SGSN. The PDP context defines different data transmissionparameters, such as the PDP type (e.g. X.25 or IP), PDP address (e.g.X.121 address), quality of service QoS and NSAPI (Network Service AccessPoint Identifier). The MS activates the PDP context with a specificmessage, Activate PDP Context Request, in which it gives information onthe TLLI, PDP type, PDP address, required QoS and NSAPI, and optionallythe access point name APN.

The quality of service QoS defines how the packet data units (PDUs) arehandled during the transmission through the GPRS network. For example,the quality of service levels (QoS) defined for the PDP addressescontrol the order of transmission, buffering (the PDU queues) anddiscarding of the PDUs in the SGSN and the GGSN, especially in thecongestion situation. Therefore, different quality of service levelswill present different end-to-end delays, bit rates and numbers of lostPDUs, for example, for the end users.

For each PDP Address a different quality of service (QoS) may berequested. For example, some PDP addresses may be associated with E-mailthat can tolerate lengthy response times. Other applications cannottolerate delay and demand a very high level of throughput, interactiveapplications being one example. These different requirements arereflected in the QoS. If a QoS requirement is beyond the capabilities ofa PLMN, the PLMN negotiates the QoS as close as possible to therequested QoS. The MS either accepts the negotiated QoS, or deactivatesthe PDP context.

Current GPRS QoS profile contains five parameters: service precedence,delay class, reliability, and mean and peak bit rates. Serviceprecedence defines some kind of priority for the packets belonging to acertain PDP context. Delay class defines mean and maximum delays for thetransfer of each data packet belonging to that context. Reliability inturn specifies whether acknowledged or unacknowledged services will beused at LLC and RLC (Radio Link Control) layers. In addition, itspecifies whether protected mode should be used in case ofunacknowledged service, and whether the GPRS backbone should use TCP orUDP to transfer data packets belonging to the PDP context. Furthermore,these varying QoS parameters are mapped to four QoS levels available atLLC layer.

There are various problems, drawbacks, undefined issues and openquestions involved with the quality of service in the GPRS.

Firstly, the above mentioned mapping of GPRS QoS parameters to four QoSlevels available at LLC layer is not well defined either. In addition,relationships between delay class and service precedence are not definedin the standard.

Secondly, the scheduling and policing based on current QoS Profile israther difficult to implement (and unspecified in the standard). Forexample, how the network elements can guarantee the delay requirements?It is too expensive to employ timers to guarantee the required delayrequirements. Moreover, the delay requirements are end-to-endrequirements: How this end-to-end delay information can be used by GPRSnetwork elements is not obvious either. In practice they cannot becauseinformation about the delay occurred in the previous network element isnot conveyed to the next element (i.e. GSN). Also policing thenegotiated mean and peak bit rates is rather difficult and would consumea lot of time and processing power. In addition, if we wanted to makesure that a certain bit rate could always be provided, we would have toreserve fixed capacity for that. This would however lead to inefficientlink capacity usage.

Interpretation of mean bit rate is questionable. GPRS network cannotguarantee a certain mean bit for a user if he or she is not transmittingat fixed speed, ie. at the mean bit rate. Otherwise, the user could havean one hour connection in which he or she has not transmitted any datafor the first 55 minutes. The user cannot assume that he or she couldtransmit data at much higher speed during the last 5 minutes in order tomeet the mean bit rate requirement. Instead, the mean bit rate can onlybe guaranteed for the rest of the connection, i.e. for the last 5minutes.

The GPRS network is not capable of meeting various QoS requirements ofInternet applications. The IP (Internet Protocol) traffic goes betweenthe mobile host and the fixed host located in an external network, e.g.in the Internet. Different Internet applications require different kindof service, i.e. QoS, from the underlying network. Thus, when the mobilehost is using GPRS to access the Internet, GPRS network should becapable of meeting various QoS requirements of Internet applications.There are actually at least two IP traffic types that should be takeninto account: real-time and non-real-time traffic. One example ofreal-time traffic is voice transmission. Email and file transfer in turnare examples of non-real-time applications.

Currently, QoS parameters can only be associated with a certain PDPcontext (i.e. a certain IP address). Setting different QoS values fordifferent applications that use the same IP address is not thereforepossible. This is a very severe drawback of the current scheme. Thecurrent GPRS specifications also define only very static QoS behaviour:QoS negotiation can only be initiated by the MS when activating the PDPcontext. To summarize the main problems: GPRS QoS scheme is too static,i.e. QoS cannot be changed the MS or the GGSN after the QoS has beennegotiated for the first time, and secondly, all applications that usethe same IP address must also use the same QoS Profile, i.e. the QoSvalues. This is obviously not enough for supporting requirements ofvarious Internet applications and traffic streams, such as voicetransmission, real-time video, compressed video, email transfer, filetransfer, and high priority control information exchange.

Internet includes at the moment two different QoS schemes: IntegratedServices and Differentiated Services. Integrated Services consists ofthree traffic types: Guaranteed Service, Controlled Load Service, andBest-Effort Service. Guaranteed Service is very difficult to providewithout introducing much overhead to the system. This overhead comesfrom the fact that end-to-end traffic flows should be established fordifferent application connections. Therefore, this requires muchdatabase management, control information exchange, and traffic policingto be performed by the system. Controlled Load providers unloadednetwork behaviour even under congestion situations. Controlled Load canbe implemented by priorities. Therefore implementing Controlled LoadService would probably be easier than Guaranteed Service, which needsstrict guarantees on transmission delays etc. Best-Effort Service doesnot need any guarantees on the QoS, and is thus very easy to implementin any network.

Differentiated Services in the Internet are based on the idea that nodata flows are needed, but instead every data packet carries QoSinformation itself. This allows very flexible and easy way to provide acertain QoS to applications. The drawback is that 100% guarantees of thecapacity cannot be given because no fixed capacity is ever allocated toa certain application flow. However, this scheme is much more efficientfrom the capacity and system point of view than the Integrated Servicesscheme.

Similar problems as describe above may arise in any mobilecommunications network.

An object of the present invention to introduce a new improved Qualityof Service (QoS) scheme which is less complicated than the prior art QoSschemes, in mobile communications systems having a packet datatransmission capability.

Another object of the present invention is a new Quality of Service(QoS) scheme which provides support for Internet applications and theirQoS requirements for mobile communications systems having a packet datatransmission capability.

An aspect of the present invention is a data transmission method.

Other aspects of the invention are a mobile communications system, anetwork element and a mobile station.

A still further aspect of the invention is a packet data communicationsnetwork.

In the present invention a dynamic packet-based quality of service (QoS)mechanism is provided within a “transmission tunnel” defined by a morestatic packet data protocol context (PDP context). More particularly,each data packet is arranged to carry at least one QoS parameter, andthe scheduling and the policing of the transmission of the data packetsis made in packet by packet basis according to this QoS information inthe packets, while, however, within the limits set by the PDP context.This concept enables to have any number of QoS profiles in usesimultaneously, e.g. a dedicated QoS profile for each of severalInternet user applications run in the mobile station for a IP address.Therefore, the present invention provides support for various Internetapplications and their QoS requirements, which cannot be provided usingthe current QoS scheme of the GPRS, for example. Moreover, the QoS canbe changed at any time after activation of the PDP context, since onlythe QoS information in the relevant data packets has to be changed. Thisovercomes the problems relating to the too static prior art QoS schemes.Further, the present invention introduces no or insignificant overheadinto the mobile communications system as a whole.

In the preferred embodiment of the invention the QoS informationassociated with each data packet include at least a priority informationand a traffic type information. The priority information has two or morevalues indicating the importance of the packet and thus also defines theorder in which data packets should be handled or discarded in case ofnetwork congestion. The priority information may also define a NominalBit Rate as in SIMA approach. The traffic type indicates requirementsfor the transmission of the packet. At least two traffic types aretypically defined: real-time and non-real-time traffic. However, moretraffic types could be defined if needed. For example, for non-real-timetraffic, the following subtypes could be used: control traffic,interactive traffic, attended bulk transfer, unattended data transfer,filler traffic, uncharacterized traffic, and best-effort traffic. Thetraffic type has an impact on retransmission strategies and dataqueueing in the network. For example, for real-time traffic,retransmissions of lost data packets are usually not needed, and it isoften better to drop real-time data packets than to send them too lateto the receiver.

In one embodiment of the invention also reliability is, instead of or inaddition to being employed at PDP context level as is currently done inthe prior art, directly associated with the QoS information in the datapacket. The communications network, e.g at the LLC layer, is arranged toprovide different connections each of which is associated with differentreliability and QoS support. These connections may be provided in anyone or several legs in the mobile communications network, e.g. at theradio interface and/or in a transmission link between two nodes in thenetwork. One connection may be a connection oriented path having ahigher reliability due to a retransmission protocol, for example, andanother connection may be a connectionless path (e.g. using a UserDatagram Protocol, UDP) having a lower reliability. Data packets aremultiplexed over these connections based on the reliability and QoSinformation. The data packets requiring reliable transmission, should besent over a reliable connection-oriented path. The data packets that donot require reliable connection-oriented path, should be sent overconnectionless path. Both the connection-oriented and the connectionlesspath can be established to transfer packets of only one PDP tunnel orthey can be used by several PDP tunnels. Furthermore, the establishmentof different paths with different reliabilties can be dynamic or static(i.e. on demand or when the tunnel (PDP context) is created). Thisconcept of the invention may applied in any packet data communicationsnetwork, even in one not using any PDP context, such as TCP/IP, ATM, orX.25 networks.

As noted above, the PDP context defines a kind transmission tunnel withspecific characteristics through a mobile communications network. As inthe conventional networks, the parameters of the PDP context may includea PDP type (e.g. X.25 or IP), a PDP address (e.g. IP address), and aNSAPI (Network Service Point Identifier). The PDP context may or may notinclude also one or more QoS parameters. For example, mean and peak bitrate for the whole PDP context might or might not be used. The QoS ofthe PDP context may also include reliability. If both the PDP-level QoSProfile and the QoS in each data packet are to be used, the trafficpolicing may be based on the QoS values related to the PDP context, e.g.on mean and peak bit rate. Therefore, if the user is sending at too highspeed, the priority of his or her data packets could be temporarydecreased by the system. This guarantees that packets not conforming tothe PDP level QoS contract are discarded first if needed. In addition,QoS information in data packets could be relevant only within the PDPcontext in question. This being the case, the QoS information in datapackets is taken into account only in relation with the QoS Profile ofthe PDP context.

A further feature of the present invention may be a mapping of the QoSparameters used in the mobile-communication network to those used in auser application in said mobile packet data terminal or those used insaid external communication system, and vice versa. The mapping is madefor each packet entering or leaving the mobile communications system.

The QoS information in the data packets may be located in a packetheader, in a lower layer protocol header, or as part of the data itself.The QoS controlling may also be based on the QoS information in QoSProfile, which is related to a certain PDP context, the priority andtraffic type information included in the data packets, or both.

One embodiment of the invention involves also a charging of the users.Users can be charged, in addition to the normal PDP level attributes, bythe priority and traffic type of data packets. This requires that themobile communications network nodes, such as GSNs in the GPRS, collectinformation on the transferred data packets and their QoS and/orpriority. On the other hand, invention also allows charging schemes thatare using the normal PDP-level attributes, such as mean and peak bitrates of the PDP context, or a combination of these schemes.

In the preferred embodiment of the invention the mobile communicationsnetwork is a packet radio network, such the General Packet Radio Service(GPRS) of GSM. The present invention may also be implemented invendor-specific ways: data packets could include priority informationalthough the current GPRS QoS Profile will still be used.

This invention will also apply to various future mobile networks, suchas UMTS.

In the following, the invention will be described in greater detail bymeans of preferred embodiments with reference to the accompanyingdrawings, in which

FIG. 1 illustrates a GPRS network architecture,

FIG. 2 illustrates a GPRS transmission plane.

The present invention can be applied to any mobile communications systemhaving a packet data transmission capability.

The term packet data protocol (PDP) as used herein should be understoodto generally refer to any state in a mobile station and in one or morenetwork element or functionality which state provides a data packettransmission path or a tunnel with a specific set of parameters throughthe mobile communications network. The term node as used herein shouldbe understood to generally refer to any network element or functionalitywhich handles the data packets transferred through the PDP channel.

The invention can be especially preferably used for providing a generalpacket radio service GPRS in the pan-European digital mobilecommunication system GSM (Global System for Mobile Communication) or incorresponding mobile communication systems, such as DCS1800 and PCS(Personal Communication System). In the following, the preferredembodiments of the invention will be described by means of a GPRS packetradio network formed by the GPRS service and the GSM system withoutlimiting the invention to this particular packet radio system.

FIG. 1 illustrates a GPRS packet radio network implemented in the GSMsystem. For a more detailed description of the GPRS, a reference is madeto ETSI GSM 03.60, version 5.1.0, and the cross-references thereof.

The basic structure of the GSM system comprises two elements: a basestation system BSS and a network subsystem NSS. The BSS and mobilestations MS communicate over radio links. In the base station system BSSeach cell is served by a base station BTS. A number of base stations areconnected to a base station controller BSC, which controls the radiofrequencies and channels used by the BTS. Base station controllers BSCare connected to a mobile services switching centre MSC. As regards amore detailed description of the GSM system, reference is made to theETSI/GSM recommendations and The GSM System for Mobile Communications,M. Mouly and M. Pautet, Palaiseau, France, 1992, ISBN:2-957190-07-7.

In the figure the 1 GPRS system connected to the GSM network comprisesone GPRS network, which in turn comprises one serving GPRS support node(SGSN) and several GPRS gateway support nodes (GGSN). The differentsupport nodes SGSN and GGSN are interconnected by an intraoperatorbackbone network. It is important to realize that in the GPRS networkthere may be any number of serving support nodes and gateway supportnodes.

The serving GPRS support node SGSN is a node which serves the mobilestation MS. Each support node SGSN controls a packet data service withinthe area of one or more cells in a cellular packet radio network, andtherefore, each support node SGSN is connected (Gb interface) to acertain local element of the GSM system. This connection is typicallyestablished to the base station system BSS, i.e. to base stationcontrollers BSC or to a base station BTS. The mobile station MS locatedin a cell communicates with a base station BTS over a radio interfaceand further with the support node SGSN to the service area of which thecell belongs through the mobile communication network. In principle, themobile communication network between the support node SGSN and themobile station MS only relays packets between these two. To realize thisthe mobile communication network provides packet-switched transmissionof data packets between the mobile station MS and the serving supportnode SGSN. It has to be noted that the mobile communication network onlyprovides a physical connection between the mobile station MS and thesupport node SGSN, and thus its exact function and structure is notsignificant with respect to the invention. The SGSN is also providedwith a signalling interface Gs to the visitor location register VLR ofthe mobile communication network and/or to the mobile services switchingcentre, e.g. signalling connection SS7. The SGSN may transmit locationinformation to the MSC/VLR and/or receive requests for searching for aGPRS subscriber from the MSC/VLR.

The GPRS gateway support nodes GGSN connect an operator's GPRS networkto external systems, such as other operators' GPRS systems, datanetworks 11-12, such as IP network (Internet) or X.25 network, andservice centers. A border gateway BG provides an access to aninter-operator GPRS backbone network. The GGSN may also be connecteddirectly to a private corporate network or host. The GGSN includes GPRSsubscribers' PDP addresses and routing information, i.e. SGSN addresses.Routing information is used for tunneling protocol data units PDU fromdata network 11 to the current switching point of the MS, i.e. to theserving SGSN. Functionalities of the SGSN and GGSN can be connected tothe same physical node.

The home location register HLR of the GSM network contains GPRSsubscriber data and routing information and maps the subscriber's IMSIinto one or more pairs of the PDP type and PDP address. The HLR alsomaps each PDP type and PDP address pair into one or more GGSNs. The SGSNhas a Gr interface to the HLR (a direct signalling connection or via aninternal backbone network 13). The HLR of a roaming MS may be in adifferent mobile communication network than the serving SGSN.

An intra-operator backbone network 13, which interconnects an operator'sSGSN and GGSN equipment can be implemented, for example, by means of alocal network, such as an IP network. It should be noted that anoperator's GPRS network can also be implemented without theintra-operator backbone network, e.g. by providing all features in onecomputer.

An inter-operator backbone network enables a communication betweendifferent operators' GPRS networks.

In order to access the GPRS services, a MS shall first make its presenceknown to the network by performing a GPRS attach. This operationestablishes a logical link between the MS and the SGSN, and makes the MSavailable for SMS over GPRS, paging via SGSN, and notification ofincoming GPRS data. More particularly, when the MS attaches to the GPRSnetwork, i.e. in a GPRS attach procedure, the SGSN creates a mobilitymanagement context (MM context). Also the authentication of the user iscarried out by the SGSN in the GPRS attach procedure.

In order to send and receive GPRS data, the MS shall activate the packetdata address that it wants to use, by requesting a PDP activationprocedure. This operation makes the MS known in the corresponding GGSN,and interworking with external data networks can commence. More,particularly a PDP context is created in the MS and the GGSN and theSGSN.

As a consequence, three different MM states of the MS are typical of themobility management (MM) of a GPRS subscriber: idle state, standby stateand ready state. Each state represents a specific functionality andinformation level, which has been allocated to the MS and SGSN.Information sets related to these states, called MM contexts, are storedin the SGSN and MS. The context of the SGSN contains subscriber data,such as the subscriber's IMSI, TLLI and location and routinginformation, etc.

In the idle state the MS cannot be reached from the GPRS network, and nodynamic information on the current state or location of the MS, i.e. theMM context, is maintained in the network. In the standby and readystates the MS is attached to the GPRS network. In the GPRS network, adynamic MM context has been created for the MS, and a logical link LLC(Logical Link Control) established between the MS and the SGSN in aprotocol layer. The ready state is the actual data transmission state,in which the MS can transmit and receive user data.

In the standby and ready states the MS may also have one or more PDPcontexts (Packet Data Protocol), which are stored in the serving SGSN inconnection with the MM context. The PDP context defines different datatransmission parameters, such as the PDP type (e.g. X.25 or IP), PDPaddress (e.g. X.121 address), quality of service QoS and NSAPI (NetworkService Access Point Identifier). The MS activates the PDU context witha specific message, Activate PDP Context Request, in which it givesinformation on the TLLI, PDP type, PDP address, required QoS and NSAPI,and optionally the access point name APN. When the MS roams to the areaof a new SGSN, the new SGSN requests MM and PDP contexts from the oldSGSN.

For a signalling and a transfer of the user information, layeredprotocol structures, referred to a transmission plane and a signallingplane, are defined in the GPRS. The signalling plane consists ofprotocols for control and support of the transmission plane functions.The transmission plane which is shown in FIG. 2 consists of a layeredprotocol structure providing user information transfer, along withassociated information transfer control procedures (e.g., flow control,error detection, error correction and error recovery). The transmissionplane independence of the Network Subsystem (NSS) platform from theunderlying radio interface is preserved via the Gb interface. GPRSTunnelling Protocol (GTP): This protocol tunnels user data andsignalling between GPRS Support Nodes in the GPRS backbone network. AllPTP PDP PDUs shall be encapsulated by the GPRS Tunnelling Protocol. GTPshall provide mechanisms for flow control between GSNs, if required. GTPis specified in GSM 09.60.

TCP carries GTP PDUs in the GPRS backbone network for protocols thatneed a reliable data link (e.g., X.25), and UDP carries GTP PDUs forprotocols that do not need a reliable data link (e.g., IP). TCP providesflow control and protection against lost and corrupted GTP PDUs. UDPprovides protection against corrupted GTP PDUs. TCP is defined in RFC793. UDP is defined in RFC 768.

IP is the GPRS backbone network protocol used for routeing user data andcontrol signalling. The GPRS backbone network may initially be based onthe IP version 4 protocol. Ultimately, IP version 6 shall be used. IPversion 4 is defined in RFC 791.

Subnetwork Dependent Convergence Protocol (SNDCP) is a transmissionfunctionality maps network-level characteristics onto thecharacteristics of the underlying network. SNDCP is specified in GSM04.65.

Logical Link Control (LLC) provides a highly reliable ciphered logicallink. LLC shall be independent of the underlying radio interfaceprotocols in order to allow introduction of alternative GPRS radiosolutions with minimum changes to the NSS. LLC is specified in GSM04.64.

Relay function relays LLC PDUs between the Um and Gb interfaces n theBSS. In the SGSN, the Relay function relays PDP PDUs between the Gb andGn interfaces.

Base Station System GPRS Protocol (BSSGP): This layer conveys routeing-and QoS-related information between BSS and SGSN. BSSGP is specified inGSM 08.18. Frame Relay layer transports BSSGP PDUs.

RLC/MAC layer contains two functions: The Radio Link Control functionprovides a radio-solution-dependent reliable link. The Medium AccessControl function controls the access signalling (request and grant)procedures for the radio channel, and the mapping of LLC frames onto theGSM physical channel. RLC/MAC is described in GSM 03.64.

Various identities are employed in the GPRS. A unique InternationalMobile Subscriber Identity (IMSI) shall be allocated to each mobilesubscriber in GSM. This is also the case for GPRS-only mobilesubscribers. A GPRS subscriber identified by an IMSI, shall have one ormore network layer addresses, i.e., PDP addresses, temporarily and/orpermanently associated with it that conforms to the standard addressingscheme of the respective network layer service used. PDP address may bea IP address or a X.121 address. PDP addresses are activated anddeactivated through MM procedures described above.

The Network layer Service Access Point Identifier (NSAPI) and TemporaryLogical Link Identity (TLLI) are used for network layer routeing. ANSAPI/TLLI pair is unambiguous within a routeing area. In the MS, NSAPIidentifies the PDP service access point (PDP-SAP). In the SGSN and GGSN,NSAPI identifies the PDP context associated with a PDP address. Betweenthe MS and SGSN, TLLI unambiguously identifies the logical link. NSAPIis a part of the tunnel identifier (TID). TID is used by the GPRSTunnelling protocol between GSNs to identify a PDP context. A TIDconsists of an IMSI and a NSAPI. The combination of IMSI and NSAPIuniquely identifies a single PDP context. The TID is forwarded to theGGSN upon PDP Context Activation and it is used in subsequent tunnellingof user data between the GGSN and the SGSN to identify the MS's PDPcontexts in the SGSN and GGSN. The TID is also used to forward N-PDUsfrom the old SGSN to the new SGSN at and after an inter SGSN routeingupdate.

Each SGSN and GGSN have an IP address, either of type IPv4 (an IPversion 4 address) or IPv6 (an IP version 6 address), forinter-communication over the GPRS backbone network. For the GGSN, thisIP address corresponds also to a logical GSN name.

GPRS transparently transports PDP PDUs between external networks andMSs. Between the SGSN and the GGSN, PDP PDUs are routed and transferredwith the IP protocol. The GPRS Tunnelling Protocol transfers datathrough tunnels. A tunnel is identified by a tunnel identifier (TID) anda GSN address. All PDP PDUs are encapsulated and decapsulated for GPRSrouteing purposes. Encapsulation functionality exists at the MS, at theSGSN, and at the GGSN. Encapsulation allows PDP PDUs to be delivered toand associated with the correct PDP context in the MS, the SGSN, or theGGSN. Two different encapsulation schemes are used; one for the GPRSbackbone network between two GSNs, and one for the GPRS connectionbetween SGSN and MS.

Between SGSN and GGSN, the GPRS backbone network encapsulates a PDP PDUwith a GPRS Tunnelling Protocol header, and inserts this GTP PDU in aTCP PDU or UDP PDU that again is inserted in an IP PDU. The IP and GTPPDU headers contain the GSN addresses and tunnel endpoint identifiernecessary to uniquely address a GSN PDP context.

Between SGSN and MS, a SGSN or MS PDP context is uniquely addressed witha TLLI and a NSAPI pair. TLLI is assigned when the MS initiates theAttach function. NSAPIs are assigned when the MS initiates the PDPContext Activation function.

The quality of service (QoS) information is employed in various nodes inthe GPRS system for scheduling and policing the transmission of the datapackets. As noted above, in the present GPRS specifications QoS isassociated with the PDP which result in various problems describedabove. According to the present invention the QoS information is, atleast partly, associated with each data packet so that the schedulingand policing can be done in packet by packet basis. More particularly,each data packet is arranged to carry at least one QoS parameter, andthe scheduling and the policing of the transmission of the data packetsis made in packet by packet basis according to this QoS information inthe packets, while, however, within a “transmission tunnel” defined bythe PDP context.

In the preferred embodiment of the invention the QoS informationassociated with each data packet include at least a priority informationand a traffic type information, and optionally, a reliabilityinformation. The priority information has two or more values indicatingthe importance of the packet and thus also defines the order in whichdata packets should be handled or discarded in case of networkcongestion. The priority information may also define a Nominal Bit Rateas in SIMA approach. The traffic type indicates requirements for thetransmission of the packet. At least two traffic types are typicallydefined: real-time and non-real-time traffic. However, more traffictypes could be defined if needed.

Adoption of the preferred embodiment of the invention requires typicallythe following modifications to be done for GPRS specifications:

1) SNDCP and GTP headers should carry additional bits for transmittingQoS information, such as priority and/or traffic class informationand/or reliability information, (GTP bits are needed on both directions,SNDCP bits could in certain cases be used only for uplink data); Inaddition, IPv4's Type-of-Service field or IPv6's priority field orTraffic Class field could be used in the GPRS backbone if it is wantedthat IP routers etc. also support prioritization of packets andQoS-based queueing or scheduling. IPv6 traffic flows may be establishedto transmit data belonging to certain traffic types. It could also bepossible that no extra bits be allocated in GTP headers, but that theclass information is carried by lower layers. For example, if theunderlying GPRS backbone network supports differentiated services, thisinformation can be included in IP or some other lower layer protocolheader. This being the case, the SGSN and the GGSN should be capable ofrecovering this lower layer information in order to reuse it. The QoSinformation can be added to data packets at the Gb interface as well,eg. to BSSGP protocol messages. Then the QoS information can be mappedto Frame Relay or ATM concepts at SGSN and BSS.

2) PDP contexts are multiplexed over several LLC SAPIs, if alsoreliability is used as a QoS parameter. In other words, SNDC layershould be capable of multiplexing NSAPI on several SAPIs at the LLClayer, as will be described in more detail below.

3) Adoption of this invention does not require any modifications to thelower radio interface protocols, like RLC. However, radio interfaceprotocols could be replaced later with newer protocols. The presentinvention is applicable also in such case and similar QoS support(prioritization, traffic type/delays) to the one described herein couldinherently be implemented into those radio protocols.

After these modifications a mapping between differentiated services inthe Internet and in GPRS may be provided as follows, for example:

priority information in the Internet is mapped to service precedence inGPRS.

real-time/non-real-time requirements in the Internet is mapped to delayclass in GPRS: at least two delay types are needed, but mapping oftraffic types more precisely to several delay classes is also possible.

The reliability information, if it is added to data packets in additionto priority and/or traffic class information, indicates the reliabilityrequirements of each application in form of one of at least tworeliability classes in the preferred embodiment of the invention. Ifreliable transmission is needed (retransmissions, checksums, TCP), datapackets are carrying reliablity class 1 information. If reliabledelivery over the radio interface is needed, but UDP in the GPRSbackbone is enough, data packets are carrying reliability class 2information. Depending on the requirements, packets may alternativelycarry reliability class 3, 4 or 5 information. Reliability classes 4 and5 will be used for real-time traffic.

A further feature of the present invention may be a mapping of the QoSparameters used in the mobile-communication network to those used in auser application in said mobile packet data terminal or those used insaid external communication system, and vice versa. The mapping is madefor each packet entering or leaving the mobile communications system. Inthe following, two examples of the mapping will be given.

EXAMPLE 1

Simple Integrated Media Access (SIMA) is a new simple approach presentedas a Internet-Draft by K. Kilkki, Nokia Research Center, June 1997.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and working groups. Since SIMA is one potentialway to provide a uniform service concept for different needs from filetransfer applications using TCP/IP protocol without loose delay andpacket loss requirements to real-time applications with very strictquality and availability requirements, it is chosen herein as an exampleof a Internet QoS scheme. According to the SIMA concept each user shalldefine only two issues before the connection setup: a nominal bit rate(NBR) and the selection between real-time and non-real-time serviceclasses. NBR may have eight values 0-7. Mapping of parameters from SIMAto GPRS and vice versa may be as follows, for example:

Real-time/non-real-time bit: if this bit indicates real-timerequirements, it is mapped to GPRS delay class 1, otherwise it is mappedto delay class 4. However, delay class 3 may be used for non-real-timeservices in case there is a special way to indicate best-effort traffic,e.g. this bit shall not always be present or a more precise definitionis used to differentiate real-time, non-real-time, and best-efforttraffic. A lower Reliability Class value may be assigned to real-timetraffic than to non-real-time traffic in GPRS. Generally, Reliabilityclasses 1, 2, and 3 are usually used for non-real-time traffic andclasses 3, 4, and 5 for real-time traffic in GPRS. For non-real-timetraffic, the higher the NBR is, the lower Reliability Class value issuitable for transmission.

Nominal Bit Rate values 6 and 7 are mapped to GPRS Service Precedenceparameter having value 1.

Nominal Bit Rate values 3, 4, and 5 are mapped to GPRS ServicePrecedence parameter having value 2.

Nominal Bit Rate values 0, 1, and 2 are mapped to GPRS ServicePrecedence value 3.

It should be noted that the Service precedence and the Delay classparameters have here a little different meaning than in the current GPRSspecifications, where those parameters are associated with PDP contexts,not with each data packet. Thus, different names, such as priority orNominal Bit Rate and traffic type, may also be chosen for theparameters. The QoS Profile may include all the existing parameters(service precedence, reliability class, delay class, mean bit rate andpeak bit rate). Alternatively, it could only include part of theparameters, such as only the mean and peak bit rate. QoS Profile couldalso include a maximum burst size parameters to ease buffer allocationprocedure.

QoS scheduling in GPRS network elements (e.g. in SGSN and GGSN) is basedon the delay class, as well as are the decisions to discard agedreal-time packets. This requires that at least two buffers should exist(and at most as many as there are different delay classes): one forreal-time packets (this buffer should be much smaller!) and the otherone for non-real-time packets. Real-time traffic should always be sentbefore non-real-time traffic. Service precendence defines the order inwhich packets can be dropped in case of network congestion.

EXAMPLE 2

Mapping Type of Service (ToS) octet in the headers of IP PDUs to GPRSpacket attributes. Type of Service octet in IP headers is not widelyused at the moment. Its original purpose was to include traffic typeinformation and to specify what kind of service is required from thepacket delivery. Because the ToS octet is not in common use nowadays, itis possible to redefine the bits in that octet for the purposes of thepresent invention. Definition of ToS octet is given in RFC 791. Bits 0-2of ToS give the preference, bits 3-5 give the ToS required by the packet(e.g. delay, throughput, and reliability levels requested), and bits 6-7are reserved for future use. RFC 1349 extends the ToS field by one bit(taken from the “reserved for future” bits). Thus, 4 bits can be used toindicate the ToS.

Mapping between the precedence bits (0-2 in ToS) and GPRS serviceprecedence may be as follows:

bit values 111 and 110 are mapped to service precedence value 001(highest priority) in GPRS.

bit values 101, 100, and 011 are mapped to service precedence value 010(normal priority) in GPRS.

bit values 010, 001, and 000 are mapped to service precedence value 011(lowest priority) in GPRS.

There are three different ways to perform the mapping between thetraffic type information (i.e. ToS field in the ToS octet) and the GPRSdelay class:

If only the bit 3 in the ToS field is used to indicate the delayrequirements in IP header: value 0 of bit 2 is mapped to GPRS delayclass 2 and value 1 of the bit 2 is mapped to GPRS delay class 4 (besteffort).

If the whole ToS field in ToS is utilized for indicating delayrequirements, i.e., 4 bits (bits 3-6) are available for that purpose,one possible mapping could be: bit value 1000 is mapped to GPRS delayclass 1 (i.e. to bit value 000), bit value 0100 to GPRS delay class 2(i.e. to value 001), ToS values 0010 and 0001 to GPRS delay class 3(i.e. to value 010), and the ToS value 0000 to GPRS delay class 4 (i.e.to value 011).

Another way of mapping IP's ToS bits to GPRS delay classes would be: 11xto delay class 1, 10x to delay class 2, 01x to delay class 3, and 00x todelay class 4. In this case, x means that there might be one or moreadditional bits used for ToS, but they do not have any impact on theprocess of selecting the GPRS delay class. If more delay classes will bedefined for GPRS later, the mapping could take into account also thoseadditional bits.

Currently there is also one bit in the IP ToS field specifying thewanted reliability level. If this bit is still available in the future,e.g., if the first choice above is chosen, this bit could carryreliability information and could be mapped to GPRS reliability class inthe following way: a value 0 in bit 5 inside the ToS octet is mapped tothe reliability class 000 (subscribed reliability class) and a value 1is mapped to the reliability class 001 (defining the most reliableservice). The use of that bit may however be too vague because the GPRSdefines many other reliability levels as well and this cannot beexpressed using only one bit.

The mapping described above in the Example 2 may be applied in a rathersimilar way in IPv6. The name of the appropriate field is then TrafficClass instead of ToS.

In the following the operation of a GPRS mobile station and GPRS networkelements, as well as Integration with external network QoS concepts,when the inventive QoS concept is employed, will be described in moredetail.

The MS, or more precisely software in the Terminal Equipment (e.g. in alaptop computer), and the GGSN provide mapping of external network QoSrequirements to GPRS QoS mechanisms, and vice versa, as described in theabove examples. Terminal Equipment (TE) could for example provide QoSfunctions through an Application Programming Interface (API). Theapplication-level software may include ToS information into the datapackets, e.g. inside the IP header, itself, or it can use the API todeliver the ToS information to lower layers. If it does not do either,the GPRS-specific software should add priority and traffic typeinformation to data packets based on the information available. Thesoftware may, for example, decide the traffic type and QoS based on theused source and destination IP addresses, or the source and destinationport numbers. Priority and traffic type information is included in everyuplink data packet by the MS. This information may be included in theToS or Traffic Class octet of the IPv4 or IPv6 header. Alternatively,this information may be carried between the Terminal Equipment and theMobile Terminal via GPRS specific mechanisms, or in PPP vendor-specificpackets/options. In addition, MS might interpret QoS informationincluded in downlink data packets and deliver this information toapplications (possibly after changing the format of information).

For Mobile Originated (MO) data, the Mobile Station (MS) schedules datapackets based on the ToS information received from the application orfrom the GPRS protocol suite in the Terminal Equipment. The MS schedulesthe incoming MO packets according to their delay class. In the SNDClayer, the MS selects the appropriate LLC SAP (Service Access Point)based on the delay requirement. If delay class 1 service is requested,SAPI 3 is used. Otherwise, the SAP to be used is chosen as follows: fordelay class 2 SAPI 5 is chosen, for delay class 3 SAPI 9 is chosen, andfor delay class 4 SAPI 11 is chosen. The choice whether to useretransmissions or checksums at LLC/RLC level may depend on thereliability class of the packet. The reliability class defines eitheracknowledged or unacknowledged service of LLC, RLC, and GTP. Schedulingin the lower layers is performed in accordance with the serviceprecedence of the corresponding packet. In addition, the MS adds thecorrect type of service and QoS information to the SNDCP data packets.This information may be included in the first data octet (or in thefirst two octets, if all three parameters, the service precedence, thedelay class, and the reliability class are included). This octet comesafter the DCOMP and PCOMP values in SN-Data PDUs and after the N-PDUnumber in SN-Unitdata PDUs.

The MS may also perform policing of the negotiated PDP contextattributes of the QoS profile. It may drop non-conformant packets orchange the service precedence (i.e. the priority) of those packets tothe worst possible, i.e. to indicate best-effort. In addition to the MS,SGSNs may perform traffic policing according to the negotiated PDPcontext QoS attributes. Network nodes may police the throughput levelsand the used delay classes, reliability classes and service precedencevalues. Values negotiated for the PDP context may be interpreted asmaximum allowed values for the packet attributes. PDP context QoSattributes may form the basis for charging,. On the other hand, packetlevel QoS may also be taken into account when billing the user. Thiswould most likely mean that there were a different counter for each datapacket type in order to be able to count how many expensive and how manycheap data packets the user has sent.

If both reliable and unreliable paths are employed between the MS andthe SGSN, it is required that the LLC layer multiplexes several NSAPI ofone user onto several SAPIs in the MS and SGSN. Logical Link Entities(LLE) may establish all connections, i.e. the SAPIs, beforehand or onlyon demand. These SAPIs/links should not be teared down immediately afterserving one request. A timer, for example, may control the tearing downof LLC connections associated with SAPIs. The SNDC layer decides, basedon the TLLI and the delay class or optionally also the reliabilityclass, which SAPI it will use to transfer the packet in question. TheSNDC layer can perform segmentation of SN-PDUs as usual. Then, the SNDClayer gives the packet to the LLC layer using the appropriate SAP. TheLLC layer transmits the packet over the LLC/radio connection as usual.At the other end, the SNDC layer receives packets from the differentLLEs and associates them with the correct NSAPIs. Ordering of packets isnot essential because packets using different QoS either belong todifferent application-level connections or are reordered based on theirQoS values, which is the purpose of QoS values in the first place.

The SGSN takes the traffic class information, i.e. the serviceprecedence, the delay class, and the reliability class, out the uplinkSNDCP packet, and schedules the packets based on their delay class.There are different buffers for each delay class. The lower the delayclass is, the smaller the size of a buffer allocated for queueing theconcerned packet class should be. This is because some packets are delaysensitive, and thus cannot cope with long queueing delays. Lower delayclasses are always sent before any higher delay class packets. Eachbuffer, i.e. a queue, may have a threshold value defined. When thisthreshold value is exceeded, the incoming packets (of the concernedclass) having a low service precedence value may be discarded. SGSN maymaintain both reliable and unreliable paths to GGSNs. These paths mightbe dedicated to a certain user/tunnel, or several users and tunnelsmight be multiplexed onto the same paths. The right path for deliveringeach data packet is selected based on the reliability class informationincluded in the packet, or based on default values if there is notenough information in the packet to make a decision. Reliableconnection-oriented path is chosed for reliability class 1, andconnectionless path for other reliability classes. SGSN adds traffictype information to GTP headers. This information may be included in theeighth octet of the header (currently reserved for future use). Thisoctet might include for example the service precedence and the delayclass information. In case the reliability class information is alsocarried in every data packet, bits 2-5 of the first octet of the GTPheader can be taken into use. These bits may contain either thisreliability class information or information on one of the otherparameters as well.

The GGSN recovers the QoS information from the uplink GTP header. It mayalso perform traffic policing. The GGSN may perform charging functionsand may utilize the packet QoS information for that purpose, too.

The GGSN, or an external host, may provide a mapping between theexternal data network QoS definitions and the GPRS QoS, and vice versa.This applies both for uplink and downlink data delivery.

For Mobile Terminated (MT) data packets, the same procedure applies,only the transmission direction is reversed. In this case, it is theGGSN who selects the appropriate GTP path, the SGSN looks inside thedownlink GTP header in order to find the traffic type and QoSinformation. The SGSN also adds the QoS information to downlink SNDCPpackets, makes the scheduling based on packet delay classes, and decidesthe correct LLC SAPI to be used. The Mobile Terminal may change theapplication's IP header in order to inform the Terminal Equipment (TE)of the QoS of the downlink data packet. Alternatively, the MS might usesome GPRS or PPP specific mechanisms for delivering the same informationto the TE. Scheduling and policing operations inside the networkelements are basically the same in both directions.

As noted above, for uplink data, the GGSN, or an external host, modifiesthe GPRS QoS information to the QoS concepts available in the externalpacket data network. Similarly, for downlink data, the GGSN, or anexternal host, should translate the external network QoS into the GPRSQoS definitions in each data packet. The GGSN, or an external host, mayoptionally maintain information about different application connectionsand traffic flows, but this is not required. The GGSN, or an externalhost, may decide the priority and traffic type of each data packet basedon this flow information. The flow information can be obtained forexample via a RSVP signalling taken place in the network. The GGSN, oran external host, may response to external RSVP messages itself, or itmay also pass the RSVP messages to the MS which may take part in theRSVP signalling. The capacity indicated in RSVP response messages shouldbe in line with the priority and traffic type values used for datapackets belonging to that flow or PDP context (related to which theGGSN, or an external host, maintains QoS information). Fixed capacityreservations are not required inside the GPRS network. To indicate this,the GGSN, or an external host, may set the Global Break Bit or the BreakBit in the RSVP messages. (These break bits indicate that there is atleast one network element along the path who cannot entirely guaranteethe QoS requested.)

As described in the examples above, the Differentiated Services in theInternet, like SIMA approach, can be mapped quite easily to these newGPRS QoS concepts. Best-Effort Service may be specified as non-real-timetraffic with a low priority. The Integrated Services are usuallyassociated with traffic flows. The Guaranteed Service can thus bedefined as with the RSVP: the GGSN, or an external host, and the MS onthe other side, may act like some fixed capacity would have beenreserved for a flow or IP context and can set “break bits” of the RSVPmessages, if necessary. The Controlled Load traffic may be supportedwithout any flows: the QoS information can be included directly into thedata packets. Also in this case, the GGSN, or an external host, and theMS may optionally maintain QoS information related to applicationtraffic flows and add the appropriate QoS information to the datapackets based on this maintained flow information. During the RSVPnegotiation, the GPRS system may indicate that it cannot support varioustoken bucket sizes or maximum packet sizes. Thus, it may require thatthose parameters are set to conform to the supported values before itwill accept the RSVP reservations. The MS, the SGSN, the GGSN or anexternal host may also know how many high priority flows (the amount ofdelay class 1 packets) the GPRS can support and make a decision on theacceptance of each reservation request based on this information.

Also ATM (Asynchronous Transfer Mode) or X.25 can be used as an externaldata network or as a transmission medium to convey the GPRS signallingand data traffic. The ATM Constant Bit Rate (CBR) and real-time VariableBit Rate (r-VBR) traffic may be mapped to real-time traffic class andthe other ATM traffic classes to non-real-time traffic. Priority may bedecised based on both the used traffic class (non-real-time Variable BitRate, Alternative Bit Rate, or Unspecified Bit Rate) and otherconnection-related parameters, such as mean and maximum bit rate.

IP networks will be used as an underlying transmission network in theGPRS backbone. The GPRS QoS concepts may be mapped to theType-Of-Service parameter in the IPv4, or to the Priority/Traffic Classfield in the IPv6, and vice versa. The flows in the IPv6 can also beused to reserve a certain kind of capacity and to handle certain traffictypes, application connections, or PDP contexts. If the externalInternet network also employs these methods, the GGSN, or an externalhost, could perform mapping of concepts similarly between the GPRSnetwork and the Internet.

Similarly as described above with respect to the GPRS, the presentinvention can be applied in any mobile communications network. Apotential mobile networks in which the principles of the presentinvention may be applied are the third generation mobile communicationssystems, such as the Universal Mobile Communications System (UMTS) andthe Future Public Mobile Telecommunication System (FPLMTS), or IMT-2000,or the Cellular Digital Packet Data (CDPD).

The description only illustrates preferred embodiments of the invention.The invention is not, however, limited to these examples, but it mayvary within the scope and spirit of the appended claims.

What is claimed is:
 1. A data transmission method for a mobilecommunications system having a packet data transmission capability,comprising: providing in the mobile communications network at least oneconnection leg with at least two paths having different reliabilities,said at least two paths including a User Datagram Protocol path with alower reliability and a Transmission Control Protocol path with a higherreliability; setting up a single packet data protocol context for amobile packet data terminal for routing data packets through the mobilecommunications system between said mobile packet data terminal and anexternal communication system; transmitting, within said single packetdata protocol context, data packets of at least two user applicationsrun in said mobile packet data terminal; providing each individual datapacket with priority information and traffic type information as qualityof service parameters, the priority information indicating one of atleast two priority levels and the traffic type information indicatingone of at least two traffic types; scheduling and policing thetransmission of each respective data packet according to said at leastone quality of service parameter carried in said respective data packet,within the limits set by said packet data protocol context; providingeach individual data packet with reliability information as a furtherquality of service parameter, said reliability information defining oneof at least two reliability classes; and multiplexing the data packetsto said at least two paths according to said reliability informationcarried in said data packets.
 2. A method as claimed in claim 1, furthercomprising: providing in the mobile communications network at least oneconnection leg with a connectionless path and a connection-oriented pathhaving different reliabilities; sending a data packet in which thereliability information indicates that a reliable transmission isneeded, over said connection-oriented path; and sending a data packet inwhich the reliability information indicates that a less reliabletransmission is needed, over said connectionless path.
 3. Method asclaimed in claim 1, wherein said mobile communications system is apacket radio network comprising serving nodes, gateway nodes and a datanetwork interconnecting said serving nodes and gateway nodes.
 4. A datatransmission method for a mobile communications system including packetradio serving nodes, packet radio gateway nodes and an IP data networkinterconnecting said packet radio serving nodes and packet radio gatewaynodes, having a packet data transmission capability, said methodcomprising: setting up a single packet data protocol context in one ofthe packet radio gateway nodes for a mobile packet data terminal forrouting data packets through the mobile communications system betweensaid mobile packet data terminal and an external communication system;transmitting, within said single packet data protocol context, datapackets of at least two user applications run in said mobile packet dataterminal; providing each individual data packet with priorityinformation and traffic type information as quality of serviceparameters, the priority information indicating one of at least twopriority levels and the traffic type information indicating one of atleast two traffic types, said at least two traffic types including areal-time traffic and a non-real-time traffic; defining at least onefurther quality of service parameter in said packet data protocolcontext said one packet radio gateway node; scheduling and policing thetransmission of each respective data packet in said mobile communicationsystem according to said at least one quality of service parametercarried in said respective data packet, within the limits set by said atleast one further quality of service parameter in said packet dataprotocol context; and mapping of quality of service parameters used inthe mobile-communication system to those used in a user application insaid mobile packet data terminal or those used in said externalcommunication system, and vice versa.
 5. A method as claimed in claim 4,wherein data packets associated with two or more packet data protocolcontexts are multiplexed to said connectionless and connection-orientedpaths in said at least one connection leg.
 6. A method as claimed inclaim 4, wherein said at least one further quality of service parameterincludes one or more of the following: mean bit rate, peak bit rate,service precedence, delay class and reliability.
 7. A method as claimedin claim 6, further comprising: providing in the mobile communicationsnetwork at least one connection leg with a connectionless path and aconnection-oriented path having different reliabilities; sending a datapacket over said connection-oriented path when the reliabilityinformation in said packet data protocol context indicates that areliable transmission is needed; and sending a data packet over saidconnectionless path when the reliability information in said packet dataprotocol context indicates that a less reliable transmission is needed.8. A method as claimed in claim 6, further comprising: monitoring theactual mean bit rate used by the mobile packet data terminal; andlowering the priority of the data packets of the mobile packet dataterminal, if said actual mean bit rate exceeds a mean bit rate definedin said packet data protocol context.
 9. A mobile communications system,comprising: mobile packet data terminals; a mobile communicationsnetwork comprising packet radio serving nodes, packet radio gatewaynodes providing an access to an external system, and an InternetProtocol data network interconnecting said packet radio serving nodesand packet radio gateway nodes; at least one connection leg with atleast two paths having different reliabilities in the mobilecommunications network; means for setting up a packet data protocolcontext in one of said packet radio gateway nodes for a mobile packetdata terminal for transmitting data packets through the mobilecommunications network between said mobile packet data terminal and anexternal communication system; at least two user applications run insaid mobile packet data terminal and transmitting data packets within asingle packet data protocol context; each individual data packet of eachof said user applications carrying at least one quality of serviceparameter indicating the quality of service required by the respectiveuser application; each individual data packet carrying priorityinformation and traffic type information as quality of serviceparameters, the priority information indicating one of at least twopriority levels and the traffic type information indicating one of atleast two traffic types; each individual data packet carryingreliability information as a further quality of service parameter, saidreliability information defining one of at least two reliabilityclasses; means for scheduling and policing responsive to said at leastone quality of service parameter carried in each respective data packetfor scheduling and policing the transmission of said respective datapacket within the limits set by said packet data protocol context; andmeans for multiplexing the data packets to said at least two pathsaccording to said reliability information carried in said data packets.10. A system as claimed in claim 9, wherein said at least one furtherquality of service parameter includes one or more of the following: meanbit rate, peak bit rate, service precedence, delay class andreliability.
 11. A system as claimed in claim 10, further comprising: atleast one connection leg with a connectionless path and aconnection-oriented path having different reliabilities in the mobilecommunications network; means for sending a data packet over saidconnection-oriented path when the reliability information in said packetdata protocol context indicates that a reliable transmission is needed;and means for sending a data packet over said connectionless path whenthe reliability information in said packet data protocol contextindicates that a less reliable transmission is needed.
 12. A system asclaimed in claim 10, further comprising: means for monitoring the actualmean bit rate used by the mobile packet data terminal; and means forlowering the priority of the data packets of the mobile packet dataterminal, if said actual mean bit rate exceeds a mean bit rate definedin said packet data protocol context.
 13. A system as claimed in claim9, further comprising means for mapping of quality of service parametersused in the mobile-communication network to those used in a userapplication in said mobile packet data terminal or those used in saidexternal communication system, and vice versa.
 14. A network element asclaimed in claim 9, wherein said mobile communications comprises servingnetwork elements and gateway network elements providing access points toexternal systems.
 15. A mobile communications system, comprising: mobilepacket data terminals; a mobile communications network comprising packetradio serving nodes, packet radio gateway nodes providing an access toan external system and an Internet Protocol data network interconnectingsaid packet radio serving nodes and packet radio gateway nodes; meansfor setting up a packet data protocol context for a mobile packet dataterminal for transmitting data packets through the mobile communicationsnetwork between said mobile packet data terminal and an externalcommunication system; at least two user applications run in said mobilepacket data terminal and transmitting data packets within a singlepacket data protocol context; each individual data packet of each ofsaid user applications carrying at least one quality of serviceparameter indicating the quality of service required by the respectiveuser application; each individual data packet carrying priorityinformation and traffic type information as quality of serviceparameters, the priority information indicating one of at least twopriority levels and the traffic type information indicating one of atleast two traffic types, said at least two traffic types including areal-time traffic and a non-real-time traffic; at least one furtherquality of service parameter defined in said packet data protocolcontext; and means for scheduling and policing responsive to said atleast one quality of service parameter carried in each respective datapacket for scheduling and policing the transmission of said respectivedata packet within the limits set by said at least one further qualityof service parameter in said packet data protocol context; and means formapping of quality of service parameters used in themobile-communication network to those used in a user application in saidmobile packet data terminal or those used in said external communicationsystem, and vice versa.
 16. A mobile station for a mobile communicationssystem having a packet data transmission capability, includingscheduling and policing means for scheduling and policing a transmissionof Internet Protocol data packets over an air-interface within limitsset by a packet data protocol context defined for said mobile station,the mobile station being configured to provide each individual IP datapacket transmitted over the air-interface with at least one quality ofservice parameter, and that said means for scheduling and policing areresponsive to said at least one quality of service parameter carried ineach respective IP data packet for scheduling and policing thetransmission of said respective IP data packet within the limits set bysaid packet data protocol context, and wherein the mobile station isarranged to convert quality of service parameters used by an applicationrun in the mobile station into service parameters used in themobile-communication system, and vice versa.